The present invention is related to the IBM invention having Ser. No. 09/533,314, entitled xe2x80x9cOn-Demand Generation, Packaging, and Delivery of Archive Filesxe2x80x9d, filed concurrently herewith on Mar. 22, 2000.
1. Field of the Invention
The present invention relates to computer programming, and deals more particularly with a method, system, and computer program product for automatically transforming software components written for stand-alone execution such that they can be executed as client/server components in a distributed network computing model.
2. Description of the Related Art
The client-server model for distributed computing has been in use for a number of years. In this model, a program called the xe2x80x9cclientxe2x80x9d makes a request for service from another program called the xe2x80x9cserverxe2x80x9d. Typically, the machines on which the client and server programs execute are different and are connected through a network such as the Internet, or a corporate intranet or extranet. Some of the code for performing the application is resident on, and executes on, the client machine while other code resides on, and executes on, the server machine.
A client/server application (that is, an application intended to be executed in a client/server distributed computing environment) is developed in a particular manner to enable the code to execute properly at run-time. An agreed-upon communications protocol must be used by both the client and server code, in order to exchange each request for service and its response.
An early protocol used with client/server computing is the Remote Procedure Call (xe2x80x9cRPCxe2x80x9d). With RPC, a programmer codes a module invocation (i.e. a procedure call) in the normal manner for the programming language in which he is writing, but only a xe2x80x9cstubxe2x80x9d for that module is generated during program compilation (where a xe2x80x9cstubxe2x80x9d is a special construct enabling the program to successfully compile without resolving the address of the referenced procedure). If the procedure is actually called during runtime, a request to execute the code will be forwarded to a server where the module is available (hence, the procedure call is a xe2x80x9cremotexe2x80x9d procedure call). That server will perform the function of the procedure, and return the results to the client workstation, transparently to the user. (For a detailed description of RPC, refer to international standard ISO/IEC 11578, xe2x80x9cRemote Procedure Call (RPC)xe2x80x9d, dated 1996.)
Another technique that enables this type of distributed computing, which is usable in object-oriented environments, is known as DSOM, or xe2x80x9cDistributed System Object Modelxe2x80x9d. SOM(copyright), or xe2x80x9cSystem Object Modelxe2x80x9d, is an International Business Machines Corporation (xe2x80x9cIBMxe2x80x9d) implementation of the CORBA(copyright) (Common Object Request Broker Architecture) standard developed by the Object Management Group. (xe2x80x9cSOMxe2x80x9d is a registered trademark of IBM, and xe2x80x9cCORBAxe2x80x9d is a registered trademark of Object Management Group, Inc.) SOM defines a way to create objects that can be accessed by programs without regard to the programming language in which the program is written, the specific compiler used to compile the programs, etc. DSOM, also from IBM, extends the SOM by defining a way to distribute SOM objects, so that they can be accessed by remotely executing applications. In addition, Microsoft has developed the Component Object Model, or COM, technology as an alternative to DSOM and CORBA. (The details of CORBA, SOM, DSOM, and COM are beyond the scope of this discussion. Reference may be made to xe2x80x9cThe Common Object Request Broker: Architecture and Specificationxe2x80x9d, OMG Document Number 91.12.1 Revision 1.1, for more information on CORBA, and to xe2x80x9cSOMobjects Publicationsxe2x80x9d, IBM document number S96F-8649, for more information on SOM and DSOM.)
The Java(trademark) programming language provides yet another technique for operating with only some portion of the executable program being loaded on the client workstation. (xe2x80x9cJavaxe2x80x9d is a trademark of Sun Microsystems, Inc.) Whereas RPC, DSOM, CORBA, and COM provide for accessing remotely-stored procedures and objects, Java provides a different approach through use of Java applets. A Java applet is a special type of software component which is intended to be dynamically downloaded at run-time to a client machine along with a Web page which invokes the code in the applet. The Java applet code modules (referred to as xe2x80x9cclassesxe2x80x9d) are loaded from their remote storage onto the client workstation if and when they are needed (i.e. if they are actually invoked during execution), so that execution occurs locally. Another Java technique is Remote Method Invocation, or xe2x80x9cRMIxe2x80x9d, which provides for execution of remotely-located Java methods, in a similar manner to that described above for remote execution using RPC, DSOM, CORBA, and COM. RMI is a technique for use in distributed Java applications, whereby the methods of a remote Java object can be invoked from other Java virtual machines, even though the virtual machine may be operating on a different server than the one on which the object is located. This is accomplished by making a reference to the object available to the application that wishes to invoke one of the object""s methods. The reference can be made available either by the application program looking up the object""s location (using a method invocation) in a bootstrap naming service provided by RMI, or by passing the reference information for the object as a parameter to the application. This reference is then used when invoking the object""s method, and serves to automatically route the request to the proper location.
The prior art techniques which have been described all provide for accessing remotely-stored codexe2x80x94whether by executing the code at the remote server (as described for RPC, DSOM, CORBA, COM, and RMI), or by downloading a copy for execution on the client machine (as described for Java applets). The remote execution techniques all have in common a requirement to provide special programming considerations, a priori, to enable the remote execution capability of each individual component. RMI, DSOM, CORBA, and COM, for example, require that a xe2x80x9cproxyxe2x80x9d version of each remotely-stored software component is generated and then distributed to the client machine(s) which will access the components. At run-time, client software using these techniques must call a search routine to locate the proxy versions. In addition, when using RMI, the remotely-stored components must be pre-registered with the RMI bootstrap naming service.
There are a number of drawbacks to these existing techniques for distributed computing. First, the special preparations which are required for remote execution make writing distributed programs more complex. In addition, once a program has been created for execution in this way, its flexibility is constrained in that it must continue to be executed in a distributed fashion (or else must be rewritten for other execution modes, such as stand-alone execution). Similarly, there is currently no convenient way for a program which is written to operate outside the distributed computing environment (as a locally-executed, stand-alone component, for example) to take advantage of the distributed model without some amount of manually rewriting the code.
Furthermore, the existing techniques for distributed computing are unsuitable in some scenarios. RPC, for example, is not adapted to object-oriented computing. And while use of applets is a very popular and powerful technique for dynamic distribution of code, there are situations in which this technique cannot operate as currently defined. In the legacy host environment, for example, software components written as objects are being developed to access legacy host data (where these objects enable, inter alia, replacing procedural language data access software developed for prior computing architectures such as the 3270 data stream architecture). For reasons which are not pertinent to the present invention, is it not possible to execute certain of these objects remotely. Instead, they must execute at a server. (The HostPublisher product from IBM may be used for accessing legacy host data with objects in this manner, in which case the objects must execute on a HostPublisher server.) Applications developed using these objects must then be written to run completely on the same server as the legacy access objects, or the application must be specially designed for the client/server environment to enable the legacy access objects to execute at the remote server while other parts of the software execute at a client. This requirement to pre-select an execution mode limits the developer""s flexibility in designing applications, and is a stumbling block to efficient deployment of an object-oriented solution to legacy data access.
Accordingly, a need exists for a technique by which these shortcomings in the prior art can be overcome. The present invention defines a novel approach to solving these problems, providing for automatic and transparent transformation of software components into components that can be used in a client/server application without requiring the code of the invoking application to be changed.
An object of the present invention is to provide a technique whereby shortcomings in prior art distributed computing techniques can be overcome.
Another object of the present invention is to provide a technique for automatically and transparently transforming components created for stand-alone execution into components that can execute in a client/server environment.
Still another object of the present invention is to provide this technique such that the code of the application which invokes the components does not need to change.
Yet another object of the present invention is to create applications and components which can execute in a stand-alone mode or in a client/server mode, without requiring a developer to change the applications or components.
It is another object of the present invention to provide this technique such that a proxy is automatically generated for the components, where the proxy will execute on the client and the component will remain remotely located.
It is yet another object of the present invention to provide this proxy generation in an on-demand, dynamic manner.
A further object of the present invention is to enable the generated proxy code to reflect the most up-to-date version of the remotely-located component.
Another object of the present invention is to enable generation of a proxy based upon the client environment from which it will be used.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for automatically transforming software components written for stand-alone execution such that they can be executed as client/server components in a distributed network computing model. This technique comprises: automatically sending a request for an archive file to a first server over a first network connection, responsive to encountering a reference to the archive file during execution of code on a client workstation, and wherein the request identifies a dynamic archive builder accessible from the first server; dynamically building the requested archive file, wherein the dynamically built archive file contains a proxy for a remote component, the proxy having an interface which is identical to that of the remote component; returning the dynamically built archive file to the client workstation and transparently accessing the remote component during execution of a program contained in the returned archive file at the client workstation, as if the remote component was being executed locally at the client workstation, by accessing the interface of the proxy.
Optionally, dynamically building the requested archive file may further comprise programmatically generating the proxy. The programmatic generation may further comprise: instantiating an instance of the remote component; determining a set of input methods used to set input properties of the instance; determining a set of output methods used to get output properties of the instance; determining one or more execution methods used to execute the instance; generating the interface to have the input methods, the output methods, and the one or more execution methods; and generating source code of the proxy to perform a different version of each of the one or more execution methods, wherein each of the different versions causes invocation of a corresponding one of the one or more execution methods of the remote component.
The transparent access may further comprise: sending a set of parameter name/value pairs which are required by the remote component from said proxy to a generic client application executing on the client workstation; forwarding the set of parameter name/value pairs from the generic client application to a generic server application over a second network connection, wherein the generic server application is executing on a second server and wherein the first network connection and the second network connection may or may not be different and the first server and the second server may or may not be different; invoking the remote component by the generic server application, using the forwarded parameter name/value pairs; and returning results of the invocation to the program.
Returning the results may further comprise: sending the results from the generic server application to the generic client application over the second network connection; forwarding the sent results from the generic client application to the proxy; using the input methods and the output methods of the generated interface to reflect the results, and obtaining the results by the program through use of the output methods.
The invoking may further comprise: instantiating an instance of a particular remote component specified by one of the parameter name/value pairs; determining a particular input method used to set a particular input property of the instance, and invoking the determined particular input method to set an input property of the instance to an input value, wherein the particular input method and the input value are specified by another one of the parameter name/value pairs; invoking a particular execution method of the instance, wherein the particular execution method is specified by yet another one of the parameter name/value pairs, and wherein the invocation yields an execution result; determining one or more output methods used to get each output property of the instance, and for invoking each of the determined output methods to get the output properties of the instance as output values; and formatting the output properties and the output values as output parameter name/value pairs, thereby creating the results of the invocation.
The remote component may be a Java bean.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.